ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group95c.txt/000105_icon-group-sender _Thu Nov 30 20:56:25 1995.msg

Internet Message Format | 1996-01-03 | 4KB

Received: by cheltenham.cs.arizona.edu; Fri, 1 Dec 1995 07:19:05 MST
From: "Richard L. Goerwitz III" <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: "Simplification" of Icon
To: [e-mail]
Date: Thu, 30 Nov 1995 20:56:25 -3000 (CST)
In-Reply-To: <[e-mail]> from "[e-mail]" at Nov 30, 95 01:59:00 pm
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Errors-To: [e-mail]

> >I'd personally love to see a language like Icon that did away with auto-
> >matic type conversions (I rarely used them anyway),
>
> Are You Kidding!!!???  That is one of the things that is the MOST BASIC about
> the appeal of something like ICON (or SNOBOL4, for that matter)...

I've always heard this, but suprisingly I rarely use the feature.  When I do
use it, it's usually in simple write() operations.  Only rarely do I use it
in any significant way.  And only rarely do I ready anyone else's code that
uses it in any significant way.  Even in those cases, I might add, a few
judicious calls to integer() or string() would generally rid the code of
automatic type conversions.

> if something is numeric, you can treat it like a number... without having
> to do manual conversions on it

"Manual" conversions are trivial, if you have the right utility functions
(which Icon does).

> Just because YOU don't use something is a damn poor reason to put it
> at the top of a list of things to propose to "simplify" out of the
> language!!!

I expressed an opinion.  Trust me:  My opinions aren't going to guide the
future development of Icon.  So there's no panic or shout, for heaven's
sake.

> Hey, if you want something "simplified", use C... it's VERY simple (by
> comparison, anyhow).  (It's also pathetic, but most of us realized THAT
> a LONG time ago!)

Don't be ridiculous.  Icon is implemented in C.  Does that mean that the
Icon development team is a bunch of pathetic fools?

> I think it's particularly sinister to claim that the language is going
> to die because nobody is going to be around to continue to evolve it,
> and then at the same time to say that it ought to be simplified...

Whenever features are removed from a language, users always gripe.  That
is why Ralph, I think, got into a support nightmare.  When version 6 did
away with some of the coexpression features, users went crazy.  They were
put back in later, despite that fact that they are little used (and where
they are used, generally they are used needlessly).  We're now to the
point where very old bugs (e.g., the random number generator) and wrong
design decisions (generation of elements in tables) have become immortal-
ized by user intransigence.

That's why I think Icon itself won't be revised.  I think that if it goes
on, it will go on in some other form, as the pet project of some energetic
and well-connected academic like Ralph.

You must understand, though, that I will not be doing any development
work on Icon.  Although I helped in trivial ways with the implementation
several years ago (e.g., starting the Unix getch code out), I'm nowhere
near the core development team.  So there's no need to take fright over
anything I've said here or bombard me with capital letters and exclama-
tion points.  I'm simply voicing harmless opinions.

As you can see from recent postings, development is pushing on, thanks
to the energies of people like Gregg.

--

   -Richard L. Goerwitz          ***  ***         [e-mail]